FB - Select count(*)
Otázka od: Miso
9. 6. 2004 9:27
Zdar,
mam nad FB table, v ktorej mam okolo 1 milion. zaznamov, ked chcem nad nou
spustit %subj.% tak vyhodnotenie trva priblizne 17 sek. !!.. table ma
primary key nad ID stlpcom, mam tam este dalsie 2 indexy..
.. druhe spustenie tohto dotazu je uz rychlejsie, ale stale to nie je
ono..ako to urychlit?..mam mu tam zadat natvrdo nejaky plan..?..aky?
Dik,
Miso
FB1.5, WXP
Odpovedá: Pavel Cisar
9. 6. 2004 10:01
Haj hou!
On 9 Jun 2004 at 10:12, Miso wrote:
> mam nad FB table, v ktorej mam okolo 1 milion. zaznamov, ked chcem nad nou
> spustit %subj.% tak vyhodnotenie trva priblizne 17 sek. !!.. table ma
> primary key nad ID stlpcom, mam tam este dalsie 2 indexy..
> .. druhe spustenie tohto dotazu je uz rychlejsie, ale stale to nie je
> ono..ako to urychlit?..mam mu tam zadat natvrdo nejaky plan..?..aky?
SELECT (*) se nijak urychlit neda, protoze vzdy pouziva table scan a
nemuze pouzivat indexy (kvuli multigeneracni architekture).
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Miso
9. 6. 2004 10:06
----- Original Message -----
From: "Pavel Cisar" <pcb@atlas.cz>
> SELECT (*) se nijak urychlit neda, protoze vzdy pouziva table scan a
> nemuze pouzivat indexy (kvuli multigeneracni architekture).
>
..takze nepomoze ked pouzijem napr. "select count (fld) from tbl" ked mam
index na fld ?..pripadne co odporucas na zistenie poctu zaznamov?
....az tak velmi to nepotrebujem, skor ma to zaujima ako to vyriesit..viem,
ze by sa dalo urobit nieco ako ulozena procedura, prip. trigger, ktory by mi
niekde znizoval/zvysoval hodnotu nejakeho pocitadla, ale mas pripadne nejake
ine riesenie..?
dik,
Miso
Odpovedá: Pavel Cisar
9. 6. 2004 11:20
Haj hou!
On 9 Jun 2004 at 10:56, Miso wrote:
>
> ----- Original Message -----
> From: "Pavel Cisar" <pcb@atlas.cz>
>
> > SELECT (*) se nijak urychlit neda, protoze vzdy pouziva table scan a
> > nemuze pouzivat indexy (kvuli multigeneracni architekture).
> >
>
> ..takze nepomoze ked pouzijem napr. "select count (fld) from tbl" ked mam
> index na fld ?..pripadne co odporucas na zistenie poctu zaznamov?
> ....az tak velmi to nepotrebujem, skor ma to zaujima ako to vyriesit..viem,
> ze by sa dalo urobit nieco ako ulozena procedura, prip. trigger, ktory by mi
> niekde znizoval/zvysoval hodnotu nejakeho pocitadla, ale mas pripadne nejake
> ine riesenie..?
Zadne reseni neexistuje, to je proste omezeni architektury ze pro
COUNT nelze pouzit index. Uzly indexu neobsahuji informace o
prislusnosti uzlu k transakci, tu obsahuji pouze radky. Pro zjisteni
zda radek je viditelny pro transakci je tedy zapotrebi vzdy nacist
samotny radek. Nelze tedy spocitat pouze uzly indexu, je zapotrebi
jeste precist radky, coz uz je lepsi cist jen radky -> table scan.
Index by se mohl pouzit pokud by jsi definoval WHERE klauzuli.
Ulozena procedura nebo trigger pro pocitani radku ti take nepomuze.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: konference@sales.cz
9. 6. 2004 18:51
> -----Original Message-----
On Behalf Of Pavel Cisar
> Ulozena procedura nebo trigger pro pocitani radku ti take nepomuze.
Ahoj.
Proc, ja to tak v jednom pripade pouzivam, mam trigger AfterInsert a
AfterDelete a pomoci neho updatuju aktualni pocet zaznamu.
Co je na tom spatne ?
Ludek
Odpovedá: Pavel Cisar
9. 6. 2004 20:12
Haj hou!
On 9 Jun 2004 at 19:51, konference@sales.cz wrote:
>
> > -----Original Message-----
> On Behalf Of Pavel Cisar
>
> > Ulozena procedura nebo trigger pro pocitani radku ti take nepomuze.
>
> Ahoj.
> Proc, ja to tak v jednom pripade pouzivam, mam trigger AfterInsert a
> AfterDelete a pomoci neho updatuju aktualni pocet zaznamu.
> Co je na tom spatne ?
1) Transakce v izolacni urovni SNAPSHOT neuvidi zmeny provedene a
potvrzene az po jejich zahajeni. A to ani pomoci SELECT COUNT, ani
pomoci triggeru.
2) Vytvaret citace v radcich aktualizovanych z triggeru na
insert/update/delete je ptakovina, protoze vytvareji uzke hrdlo pro
propustnost. Uzivatel B nebude schopen vlozit, zmenit nebo smazat
radek, pokud uzivatel A proved podobnou zmenu na jinem radku, ktera
rovnez vyvola aktualizaci citace, dokud uzivatel A nepotvrdi
transakci. Pokud ma NOWAIT transakci, tak to rovnou vyhuci na chybu,
pokud ma WAIT transakci tak mu to sice nejspis projde (zalezi na
izolacni urovni transakce), ale bude cekat.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: konference@sales.cz
10. 6. 2004 14:20
> -----Original Message-----
On Behalf Of Pavel Cisar
> 1) Transakce v izolacni urovni SNAPSHOT neuvidi zmeny provedene a
> potvrzene az po jejich zahajeni. A to ani pomoci SELECT COUNT, ani
> pomoci triggeru.
>
> 2) Vytvaret citace v radcich aktualizovanych z triggeru na
> insert/update/delete je ptakovina, protoze vytvareji uzke hrdlo pro
> propustnost. Uzivatel B nebude schopen vlozit, zmenit nebo smazat
> radek, pokud uzivatel A proved podobnou zmenu na jinem radku, ktera
> rovnez vyvola aktualizaci citace, dokud uzivatel A nepotvrdi
> transakci. Pokud ma NOWAIT transakci, tak to rovnou vyhuci na chybu,
> pokud ma WAIT transakci tak mu to sice nejspis projde (zalezi na
> izolacni urovni transakce), ale bude cekat.
Ahoj.
Aha. No ja to mam pouzite na tabulce, kam se zaznamy vice pridavaji nez
mazou a spise ve velkych davkach pricemz soubeh prace dvou uzivatelu nad
touto tabulkou co se tyce updatu je opravdu velkou vyjjimkou, nicmene
tabulka ma hodne zaznamu a tohle se jevilo jako dobre reseni.
Ludek